1. Introduction
Since the earliest history, various institutions (e.g., governments and private companies alike) have recorded their actions and transactions. Subsequent generations have used these archival records to understand the history of the institution, the national heritage, and the human journey. These records may be essential to support the efficiency of the institution, to protect the rights of individuals and businesses, and/or to ensure that the private company or public corporation/company is accountable to its employees/shareholders and/or that the Government is accountable to its citizens.
With the advance of technology into a dynamic and unpredictable digital era, evidence of the acts and facts of institutions and the government and our national heritage are at risk of being irrecoverably lost. The challenge is pressing—as time moves forward and technologies become obsolete, the risks of loss increase. It will be appreciated that a need has developed in the art to develop an electronic records archives system and method especially, but not only, for the National Archives and Records Administration (NARA) in a system known as Electronic Records Archives (ERA), to resolve this growing problem, in a way that is substantially obsolescence-proof and policy neutral. While embodiments of the invention will be described with respect to its application for safeguarding government records, the described embodiments are not limited to archives systems applications nor to governmental applications and can also be applied to other large scale storage applications, in addition to archives systems, and for businesses, charitable (e.g., non-profit) and other institutions, and entities.
One aspect of the invention is directed to an architecture that will support operational, functional, physical, and interface changes as they occur. In one example, a suite of commercial off-the-shelf (COTS) hardware and software products has been selected to implement and deploy an embodiment of the invention in the ERA, but the inventive architecture is not limited to these products. The architecture facilitates seamless COTS product replacement without negatively impacting the ERA system.
1.1 Understanding the Problem
Another aspect of the ERA is to preserve and to provide ready access to authentic electronic records of enduring value.
In one embodiment, the ERA supports and flows from NARA's mission to ensure “for the Citizen and the Public Servant, for the President and the Congress and the Courts, ready access to essential evidence.” This mission facilitates the exchange of vital ideas and information that sustains the United States of America. NARA is responsible to the American people as the custodian of a diverse and expanding array of evidence of America's culture and heritage, of the actions taken by public servants on behalf of American citizens, and of the rights of American citizens. The core of NARA's mission is that this essential evidence must be identified, preserved, and made available for as long as authentic records are needed—regardless of form.
The creation and use of an unprecedented and increasing volume of Federal electronic records—in a wide variety of formats, using evolving technologies—poses a problem that the ERA must solve. An aspect of the invention involves an integrated ERA solution supporting NARA's evolving business processes to identify, preserve, and make available authentic, electronic records of enduring value—for as long as they are needed.
In another embodiment, the ERA can be used to store, process, and/or disseminate a private institution's records. That is, in an embodiment, the ERA may store records pertaining to a private institution or association, and/or the ERA may be used by a first entity to store the records of a second entity. System solutions, no matter how elegant, may be integrated with the institutional culture and organizational processes of the users.
1.1.1 NARA's Evolving Business Processes
Since 1934, NARA has developed effective and innovative processes to manage the records created or received, maintained or used, and destroyed or preserved in the course of public business transacted throughout the Federal Government. NARA played a role in developing this records lifecycle concept and related business processes to ensure long-term preservation of, and access to, authentic archival records. NARA also has been instrumental in developing the archival concept of an authentic record that consists of four fundamental attributes: content, structure, context, and presentation.
NARA has been managing electronic records of archival value since 1968, longer than almost anyone in the world. Despite this long history, the diverse formats and expanding volume of current electronic records pose new challenges and opportunities for NARA as it seeks to identify records of enduring value, preserve these records as vital evidence of our nation's past, and make these records accessible to citizens and public servants in accordance with statutory requirements.
The ERA should support, and may affect, the institution's (e.g., NARA's) evolving business processes. These business processes mirror the records lifecycle and are embodied in the agency's statutory authority:                Providing guidance to Federal Agencies regarding records creation and records management;        Scheduling records for appropriate disposition;        Storing and preserving records of enduring value; and/or        Making records available in accordance with statutory and regulatory provisions.        
Within this lifecycle framework, the ERA solution provides an integrated and automated capability to manage electronic records from: the identification and capture of records of enduring value; through the storage, preservation, and description of the records; to access control and retrieval functions.
Developing the ERA involves far more than just warehousing data. For example, the archival mission is to identify, preserve, and make available records of enduring value, regardless of form. This three-part archival mission is the core of the Open Archival Information System (OAIS) Reference Model, expressed as ingest, archival storage, and access. Thus, one ERA solution is built around the generic OAIS Reference Model (presented in FIG. 1), which supports these core archival functions through data management, administration, and preservation planning.
The ERA may coordinate with the front-end activities of the creation, use, and maintenance of electronic records by Federal officials. This may be accomplished through the implementation of disposition agreements for electronic records and the development of templates or schemas that define the content, context, structure, and presentation of electronic records along with lifecycle data referring to these records.
The ERA solution may complement NARA's other activities and priorities, e.g., by improving the interaction between NARA staff and their customers (in the areas of scheduling, transfer, accessioning, verification, preservation, review and redaction, and/or ultimately the ease of finding and retrieving electronic records).
1.1.2 Encompassing a Broad Scope of Records
Like NARA itself, the scope of ERA includes the management of electronic and non-electronic records, permanent and temporary records, and records transferred from Federal entities as well as those donated by individuals or organizations outside of the government. Each type of record is described and/or defined below.
ERA and Non-Electronic Records: Although the focus of ERA is on preserving and providing access to authentic electronic records of enduring value, the system's scope also includes, for example, management of specific lifecycle activities for non-electronic records. ERA will support a set of lifecycle management processes (such as those used for NARA) for appraisal, scheduling, disposition, transfer, accessioning, and description of both electronic and non-electronic records. A common systems approach to appraisal and scheduling through ERA will improve the efficiency of such tasks for non-electronic records and help ensure that permanent electronic records are identified as early as possible within the records lifecycle. This same common approach will automate aspects of the disposition, transfer, accessioning, and description processes for all types of records that will result in significant workflow efficiencies. Archivists, researchers, and other users may realize benefits by having descriptions of both electronic and non-electronic records available together in a powerful, universal catalog of holdings. In an embodiment, some of ERA's capabilities regarding non-electronic records may come from subsuming the functionality of legacy systems such the Archival Research Catalog (ARC). To effectively manage lifecycle data for all types of records, in certain embodiments, ERA also may maintain data interchange (but not subsume) other legacy systems and likely future systems related to non-electronic records.
Permanent and Temporary Records: There is a fundamental archival distinction between records of enduring historic value, such as those that NARA must retain forever (e.g., permanent records) and those records that a government must retain for a finite period of time to conduct ongoing business, meet statutory and regulatory requirements, or protect rights and interests (e.g., temporary records).
For a particular record series from the US Federal Government, NARA identifies these distinctions during the record appraisal and scheduling processes and they are reflected in NARA-approved disposition agreements and instructions. Specific records are actually categorized as permanent or temporary during the disposition and accessioning processes. NARA takes physical custody of all permanent records and some temporary records, in accordance with approved disposition agreements and instructions. While all temporary records are eventually destroyed, NARA ultimately acquires legal (in addition to physical) custody over all permanent records.
ERA may address the distinction between permanent and temporary records at various stages of the records life-cycle. ERA may facilitate an organization's records appraisal and scheduling processes where archivists and transferring entities may use the system to clearly identify records as either permanent or temporary in connection with the development and approval of disposition agreements and instructions. The ERA may use this disposition information in association with the templates to recognize the distinctions between permanent and temporary records upon ingest and manage these records within the system accordingly.
For permanent records this may involve transformation to persistent formats or use of enhanced preservation techniques to insure their preservation and accessibility forever. For temporary records, NARA's Records Center Program (RCP) is exploring offering its customers an ERA service to ingest and store long-term temporary records in persistent formats. To the degree that the RCP opts to facilitate their customers' access to the ERA for appropriate preservation of long-term temporary electronic records, this same coordination relationship with transferring entities through the RCP will allow NARA to effectively capture permanent electronic records earlier in the records lifecycle. In the end, ERA may also provide for the ultimate destruction of temporary electronic records.
ERA and Donated Materials: In addition to federal records, NARA also receives and accesses donated archival materials. Such donated collections comprise a significant percentage of NARA's Presidential Library holdings, for example. ERA may manage donated electronic records in accordance with deeds of gift of deposit agreements which, when associated with templates, may ensure that these records are properly preserved and made available to users. Although donated materials may involve unusual disposition instructions or access restrictions, ERA should be flexible enough to adapt to these requirements. Since individuals or institutions donating materials to NARA are likely to be less familiar with ERA than federal transferring entities, the system may also include guidance and tools to help donors and the NARA appraisal staff working with them insure proper ingest, preservation, dissemination of donated materials.
1.1.3 Meeting the Needs of Users
Systems are designed to facilitate the work of users, and not the other way around. One or more of the following illustrative classes of users may interact with the ERA: transferring entity; appraiser; records processor; preserver; access reviewer; consumer; administrative user; and/or a manager. The ERA may take into account data security, business process re-engineering, and/or systems development and integration. The ERA solution also may provide easy access to the tools the users need to process and use electronic records holdings efficiently.
1.2 Mitigating Risks and Meeting Challenges
NARA must meet challenges relating to archival of massive amounts of information, or the American people risk losing essential evidence that is only available in the form of electronic federal records. But beyond mitigating substantial risks, the ERA affords such opportunities as:                Using digital communication tools, such as the Internet, to make electronic records holdings, such as NARA's, available beyond the research room walls in offices, schools, and homes throughout the country and around the world;        Allowing users to take advantage of the information-processing efficiencies and capabilities afforded by electronic records;        Increasing the return on the public's investment by demonstrating technological solutions to electronic records problems that will be applied throughout our digital society in a wide variety of institutional settings; and/or        Developing tools for archivists to perform their functions more efficiently.        
According to one aspect of the invention, there is provided a system for ingesting, storing, and/or disseminating information. The system may include an ingest module, a storage module, and a dissemination module that may be accessed by a user via one or more portals.
In an aspect of certain embodiments, there is provided a system and method for automatically identifying, preserving, and disseminating archived materials. The system/method may include extreme scale archive storage architecture with redundancy or at least survivability, suitable for the evolution from terabytes to exabytes, etc.
In another aspect of certain embodiments, there is provided an electronic records archives (ERA), comprising an ingest module to accept a file and/or a record, a storage module to associate the file or record with information and/or instructions for disposition, and an access or dissemination module to allow selected access to the file or record. The ingest module may include structure and/or a program to create a template to capture content, context, structure, and/or presentation of the record or file. The storage module may include structure or a program to preserve authenticity of the file or record over time, and/or to preserve the physical access to the record or file over time. The access module may include structure and/or a program to provide a user with ability to view/render the record or file over time, to control access to restricted records, to redact restricted or classified records, and/or to provide access to an increasing number of users anywhere at any time.
The ingest module may include structure or a program to auto-generate a description of the file or record. Each record may be transformed, e.g., using a framework that wraps and computerizes the record in a self-describing format with appropriate metadata to represent information in the template.
The ingest module, may include structure or a program to process a Submission Information Package (SIP), and/or an Archive Information Package (AIP). The access module may include structure or a program to process a Dissemination Information Packages (DIP).
Independent aspects of the invention may include the ingest module alone or one or more aspects thereof, the storage module alone or one or more aspects thereof; and/or the access module alone or one or more aspects thereof.
Still further aspects of the invention relate to a methods for carrying out one or more functions of the ERA or components thereof (ingest module, storage module, and/or access module).
1.3 Archival Problems in General and Drawbacks of Existing Solutions
The challenges faced by NARA are typical of broader archival problems and reveal drawbacks associated with known solutions. Thus, in an embodiment, an ERA may be provided to address some or all of the more general problems. In particular, archives systems exist for storing and preserving electronic assets, which are stored as digital data. Typically, these assets are preserved for a period of time (retention time) and then deleted. These systems maintain metadata about the assets in asset catalogs to facilitate asset management. Such metadata may include one or more of the following:                Attributes to uniquely identify assets;        Attributes to describe assets;        Attributes to facilitate search through the archives;        Attributes to define asset structure and relationships to other assets;        Attributes to organize assets;        Attributes for asset protection;        Attributes to maintain information about asset authenticity; and/or        Status of the asset lifecycle (e.g., planning receipt of asset through eventual deletion).        
Unfortunately, these systems all suffer from several drawbacks. For example, there are limitations relating to the scale of the assets managed and, in particular, the size and number of all the assets maintained. These systems also have practical limitations in the duration in which they retain assets. Typically, archives systems are designed to retain data for years or sometimes decades, but not longer. As retention times of assets become very long or indefinite, longevity of the archives system itself, as well as the assets archived, is needed because an archives system's basic requirement is to preserve assets.
But indefinite longevity of an archives system and its assets pose challenges. For example, providing access to old electronic assets is complicated by obsolescence of the asset's format. Regular upgrades of the archives system itself, including migrations of asset data and/or metadata to new storage systems is complicated by extreme size of the assets managed, e.g., if the metadata has to be redesigned to handle new required attributes or to handle an order of magnitude greater number of assets than supported by the old design, then the old metadata generally will have to be migrated to the new design, which could entail a great deal of migration. Extreme scale and longevity make impractical archives systems that are not designed to accommodate unknown, future changes and reduce the impact of necessary change as much as possible.
Archives systems today are built on top of underlying storage systems based on commercial products that are typically comprised of file systems (e.g., Sun's ZFS file system) or relational databases (e.g., Oracle), and sometimes proprietary systems (e.g., EMC Centera). All of these storage systems have limitations in terms of scale (though sometimes the limits can be quite high). In some cases, there may be no products that can make use of the full scale of available file systems. Few of these systems can scale to trillions of entries (e.g., files). Limitations arise for different reasons but can be related to one or more of the following factors, alone or in combination:                Limitations of object or file identification schemes (e.g., uniqueness of identifiers. www.doi.org provides background on the state of the art for electronic/digital entity identifiers.);        Catalog limitations (e.g., number of entries, design bottlenecks);        The number of storage subsystems that can be integrated (sometimes termed horizontal scalability);        The capacity of underlying storage technologies;        Search and retrieval performance considerations (e.g., search can become impractical with extreme size);        The ability to distribute system components (e.g., systems can be difficult to distribute geographically); and/or        Limitations of system maintenance tasks that are a function of system size (e.g., systems can become impractical to administer with extreme size).        
Currently, relational databases (DBs) can scale only to 10 billion objects per instance. Relational DBs also generally do not perform as well as file systems for simple search and retrieval function tasks because they tend to introduce additional overhead to meet other requirements such as fine-grained transactional integrity. There is also no viable product that integrates multiple file systems in a way that provides both extreme scaling and longevity suitable for an archives file system.
2. The Asset Catalog of Certain Example Embodiments
The asset catalog is one component of the ERA system. It may hold metadata that helps understand and manage assets in the Electronic Archives. It also may be structured to support and/or enable search (e.g., federated search) and browse functions to enable users to locate assets of interest. Because there typically is at least one catalog entry for every asset (plus entries representing asset aggregates), the asset catalog must be able to scale to very large numbers of catalog entries while providing useful search features and interactive performance. Furthermore, the asset catalog may be used to help access particular assets or collections of assets. It also may be updated with every ingest and with every accession.
The embodiments disclosed herein represent technical approaches and specific implementations capable of meeting ERA requirements for the asset catalog. One aspect of the embodiments disclosed herein relates to data storage models, and another aspect of the embodiments disclosed herein relates to search server architectures. Two fundamentally different solution classes were implemented using commercially available products. First, a database storage with integrated text search was implemented using products available from Oracle. Second, a file system storage with a separate text search engine was implemented using products available from Autonomy. The products were used as exemplars to evaluate the scalability, performance, functionality, and flexibility characteristics of various storage models and server architectures, and thus the present invention is not limited to such commercial products and the structures associated therewith. To test the overall viability of the configurations, the products were installed and loaded with several million synthetic asset catalog entries and exercised with representative queries. The illustrative schema and the illustrative dictionary used when creating the synthetic asset catalog are set forth below in Section 10. Query functionality, query response time, data storage usage, schema flexibility, and various issues encountered were explored.
It has been determined that a text search engine (e.g., Autonomy) with catalog entries stored as XML documents in a file system provides an advantageous combination of scalability, performance, functionality, and flexibility. This solution may combine the rich text-search features offered by search engines with the known scalability provided by simple file system storage. In addition, this solution may provide the flexibility to use a variety of search products with a variety of file system products, reducing risk and improving evolvability. Missing capabilities (such as XQuery support and intra-record transaction capabilities) are not necessarily a significant concern, because catalog entries generally will be stored and retrieved as whole items. It also has been determined that storing XML documents as shredded XML in an object-relational DBMS (e.g., Oracle) is an acceptable alternative, when several ERA functional search requirements (e.g., keyword suggest) are relaxed or the cost of custom implementation can be borne.
With respect to a search server architecture, it has been determined that a “federation” of multiple search server instances provides an advantageous result. A federator component may be bought or built, because database/search products generally either do not provide them or use proprietary schemas. Furthermore, the search server architecture can be augmented with distributed indexing, clustering, caching, and/or logical partitioning to improve performance and availability.
In certain embodiments, the catalog may be partitioned based on, for example, level of detail (e.g., aggregate vs. individual asset item), the need to phase in search requirements on item-level catalog entries, etc. Because there is likely to be limited or no useful metadata at the item level, indexing item-level catalog entries generally will provide no useful benefits. By focusing search functionality in the near-term on aggregate-level catalog entries then using browse (e.g., from search results) to access item-level catalog entries, the number of search servers required can be greatly reduced from hundreds or thousands to as few as one or two. Additionally or in the alternative, search server federation also can be used to gracefully expand search capabilities over time to the item level as additional metadata (e.g., content summaries) becomes available.
One aspect of certain embodiments relates to storing aggregate-level and item-level catalog entries in the file system in separate directories. Another aspect of certain embodiments relates to using a single instance of a text search engine to index and search aggregate entries only, and providing browse links from aggregate entries to detail entries. Still another aspect of certain embodiments relates to a federator being implemented to standardize the query interface and provide for future growth.
According to certain example embodiments, an extremely large scale computer storage system is provided. An asset catalog may comprise a plurality of asset catalog entries stored according to at least one schema and corresponding to a plurality of assets. A storage architecture may be capable of storing the plurality of assets, with the storage architecture comprising a storage locator and a federator. An item identification scheme may be capable of providing identifiers to reference, locate, and/or access said assets and/or said asset catalog entries stored in the asset catalog in the storage architecture. The computer storage system may be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
According to certain other example embodiments, a method of managing an extremely large scale computer storage system is provided. An asset catalog comprising a plurality of asset catalog entries stored according to at least one schema and corresponding to a plurality of assets may be provided. A storage architecture may store the plurality of assets, with the storage architecture comprising a storage locator and a federator. Identifiers may be provided via an item identification scheme to locate, access, and/or reference assets and/or asset catalog entries stored in the asset catalog in the storage architecture. The computer storage system may be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
According to certain other example embodiments, an extremely large scale computer storage system is provided. An asset catalog may be configured to store and/or retrieve a plurality of asset catalog entries. A storage architecture may be capable of storing a plurality of assets and at least one of the plurality of asset catalog entries in at least one storage location in dependence on at least one storage rule. A search interface may be configured to cooperate with one or more search engines to enable indexing of and/or searching for at least one of the asset catalog entries. A federator may be configured to mediate within and/or between the search interface and/or the storage architecture. The plurality of asset catalog entries may include at least entries corresponding to all assets persisted in the computer storage system. The plurality of assets in the storage architecture and the asset catalog entries may be identifiable based on a substantially immutable identification scheme. The asset catalog entries may be represented according to at least one schema. Each asset catalog entry may be representable in an arbitrary relationship with another asset catalog entry. The at least one storage location may be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
According to still other example embodiments, a system comprising an item identification scheme and/or subroutine, an asset catalog, and a storage subsystem may be provided. The item identification scheme and/or subroutine may associate item (e.g., asset and/or asset catalog entry) identifiers with one or more characteristics. Such characteristics may be structured to support partitioning and/or federation of stored elements (such as asset catalogs and asset repositories) and/or efficient mapping of identifiers to physical storage locations; may be universally unique such that relations and component references may span storage partitions and/or instances of a federations (comprising either or both of component references that are pointers in the asset catalog entry to the physical elements that make up the asset, and relations that are the links among asset catalog entries that are used to create logical and other derived assets, such as collections); and/or may be immutable so that eventual migration of the asset catalog to update obsolete identifiers is avoided, and external references made using these identifiers do not become invalid over time. The asset catalog may include asset catalog entries that together comprise the mechanisms to provide extreme scalability and flexibility. A schema may provide both specific and general metadata tags to provide indexing for search and access, efficiency and flexibility in metadata capture, and interpretation of metadata; support arbitrary relations between catalog entries and component assets to enable multiple views or taxonomies of the assets to be represented; support both parent-child and child-parent relations for flexibility and scalability; support browsing relations such that all assets are reachable even if only a portion have been indexed for searching; provide for multiple representations of the components of an asset to enable long-term preservation, redaction, versioning, and other functions; provide for multiple components with relationships between components to allow efficient cataloging of large numbers of asset components; utilize the item identification scheme described above, which imbues in the asset catalog the advantageous characteristics of the identifiers described above; use label security (e.g., a security mechanism where objects have a security label identifying the access required and where users are assigned the security labels to which they are granted access, generally in contrast to access control lists, which identify users for each object that can access the object; also in contrast to group access, which identify groups (of users) for each object than have access) to enable manageability for very large numbers of assets [it would be impractical to tag all those assets with users; and/or use a tagged-text (e.g., XML) format to enable catalog entries to be stored in a variety of technologies including file systems, relational databases, and object databases, and to enable recovery of content even if schema design information is lost or corrupted (e.g., humans may make sense of XML data by reading the tags even if the XML schema for these XML documents is lost). The storage structure of the asset catalog may be partitioned and/or federated based on the item identification scheme above to enable highly-scalable federated search of the catalog and to provide autonomy in the management of different catalog instances. The overall storage subsystem may comprise mechanisms to provide extreme scalability, flexibility, and longevity. In particular, a storage locator and/or federator may use the structured identifiers above to enable transparent partitioning and federation of storage subsystems; map items to storage locations using item metadata to enable physical storage structures to reflect business requirements or to partition items based on their characteristics to enable search and/or access optimization, and to enable assets and corresponding catalog entries to be physically stored together to improve portability and recoverability (e.g., to allow transparency of: storage locations should they change, data migration to new platforms, use of new commercial storage systems for storage, etc.); allow items to be mapped to multiple locations to improve access performance and availability (e.g., there may be three inputs to the storage locator: metadata, structured identifiers, URI qualifier, with the last indicating whether a replica is to be stored somewhere for a specific purpose, e.g., in both the authoritative repository and a cache repository, thus supporting performance, or a primary and secondary repository thus supporting disaster recovery and/or availability); use URIs for item access to allow transparent usage of multiple types of storage systems/technologies including file systems, relational databases, and object databases; and/or record item storage locations using patterns that have portions for which substitution is done, e.g., of an item identifier, to greatly reduce the size of this storage mapping database used by the locator to find items in storage. This last concept is another aspect that supports scalability—for example, the part and item may be left blank, so that the table entry can indicate where all items for a given package are stored, which keeps the number of entries down by several orders of magnitude.
According to certain example embodiments, a storage architecture for use with an extremely large scale computer storage system is provided. At least one storage location may be capable of storing a plurality of assets and/or a plurality of asset catalog entries corresponding to the plurality of assets. An object identification service may provide immutable and scalable identifiers for each said asset and each said asset catalog entry. A storage locator may include a mapping database to map assets and/or asset catalog entries to the at least one storage location. A federator also may be provided. The storage architecture may be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
According to certain other example embodiments, a computer-implemented method of maintaining a storage architecture for use with an extremely large scale computer storage system is provided. At least one storage location may be provided to store a plurality of assets and/or a plurality of asset catalog entries corresponding to the plurality of assets. An object identification service may be provided to provide immutable and scalable identifiers for each said asset and each said asset catalog entry. A storage locator including a mapping database may be provided to map assets and/or asset catalog entries to the at least one storage location. A federator may be provided. The storage architecture may be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
According to certain example embodiments, a computer-implemented immutable identification scheme tangibly stored on a computer-readable storage medium for use with an asset catalog and an extremely large scale computer system having an associated storage architecture is provided. The identification scheme may comprise a plurality of identifiers to reference, locate, and/or access a plurality of assets and/or a plurality of asset catalog entries stored in the asset catalog. The identification scheme may enable the asset catalog and/or the large scale computer system to be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
According to certain other example embodiments, a computer-implemented method of managing an immutable identification scheme for use with an asset catalog and an extremely large scale computer system having an associated storage architecture is provided. The method may comprise providing a plurality of identifiers to reference, locate, and/or access a plurality of assets and/or a plurality of asset catalog entries stored or to be stored in the asset catalog and/or large scale computer system to enable the asset catalog and/or the large scale computer system to be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.
It will be appreciated that as used herein, the term “subroutine” is broad enough to encompass any suitable combination of hardware, software, and any other form of programmed logic circuitry capable of accomplishing a specified function. It also will be appreciated that the above-described embodiments, and the elements thereof, may be used alone or in various combinations to realize yet further embodiments. For example, the asset catalog, storage subsystem, and item identification scheme each may be used separately or in any combination.
Other aspects, features, and advantages of this invention will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, which are a part of this disclosure and which illustrate, by way of example, principles of this invention.